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(57) Abstract: The present invention includes a merchant system (105) that recognizes virtually any payment device (120) or tech- 
nology that uses electronic check processing as a payment mechanism. For example, the merchant system (105) associates presenta- 
tion of the payment device (120) with information used to electronically debit a checking account, such as MICR data, and submits 
the same to a transaction processor (115) capable of settling electronic debit transactions. 
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ALTERNATIVE PAYMENT DEVICES USING ELECTRONIC CHECK PROCESSING AS A PAYMENT 

MECHANISM 

5 FIELD OF THE INVENTION 

The pfBsent invention relates to the field of electronic commercial transactions. More specifically, 
the Invention relates to merchant systems designed to recognize alternative payment devices that use 
electronic check processing as a payment mechanism. 

BACKGROUND OF THE INVENTION 

1 0 Consumers and merchants in today's marketplace have access to a wkle variety of technologies for 

extending credit or othenwise transferring monies for goods or services ("products"). For example, consumer 
and merchants use traditional debit technologies such as paper checks. A check refers to a draft or order for 
a certain sum of money payable on demand to a certain named entity, the entity's order, or to the bearer 
thereof. Generally, the face of a check includes magnetic ink character recognition ("MICR") characters that 

15 can be read electronically. The iVIICR characters typically include a checking account number, the bank 
transit number, the check sequence number, and the like. In addition, the MICR characters may indicate 
whether the check is a company check or a personal check. The forni or font of the MICR characters and 
their position along the bottom edge of the check are generally prescribed by standards promulgated by the 
American National Standards Institute {"ANSI"), which are incorporated by reference herein. 

20 Paper checks are generally processed through clearinghouse ("ACH') networics. which can include 

some or all banks, clearinghouse corporations, the Federal Reserve bank, or the like. For example, a payor, 
or check writer, may authorize an originator, such as a grocery store, to debit the payor's checking account by 
writing a check for, for example, groceries. The originator fonwards the authorization to an originating 
depository financial institution ("ODFI"). such as the grocer's bank. The ODFI sends the authorization through 

25 the ACH networic to a receiving deppsitory financial Institution fRDFr). such as the payor's bank. The RDFI 
then can transfer funds by debiting the payor's checking account and sending a credit through the ACH 
networic to the ODFI, or grocer's bank. 

To avoid many drawbacks associated with the foregoing paper check processing, such as 
processing delays measured in man> days and sometimes in one or more weeks, ACH networics now provide 
30 for electronic check processing. For example, merchants can now have personal checks converted to 
electronic ACH debits, often by scanning in paper check data at the point-of-sale, and returning the paper 
copy of the check to the consumer. The paper check data generally includes data representing the MICR 
characters, an amount, a payee, a scan of one or both sides of the paper check, and the like. As can be 
expected, the electronic ACH debits can be processed at much greater speeds due at least in part to the lack 
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Of paper handling that will occur. Moreover, some banks are processing a day's electronic items prior to 
processing the da/s paper items. 

The decreased processing delays associated with the, electronic ACH debits often advantageously 
provide more consistent deposit patterns back to merchants and decrease the delay in discovering and 
stopping the use of fraudulent checks. Additionally, as discussed in the foregoing, electronic ACH debits also 
advantageously allow merchants to immediately retum the paper check to the customer. 

Other technologies available to consumers and merchants in today's mari(etplace include traditional 
credit and debit card technologies. While these traditional card technologies enjoy wide acceptance as a 
method of paying for products both in modem online and traditional paper processing environments, they 
have significant drawbacks for consumers and for merchants. For example, as compared vwith the banking 
population, a much smaller percentage of consumers have or use one or more credit or debit canls. 
Moreover, the issuer of card technotogies often charges high interest rates to the consumer, while also 
chaiging high fixed or high variable processing fees to merchants. The high rates often render smaller 
incremental charges via traditional card technologies impractical. Also, more and more consumere are unable 
1 5 or unwilling to pay down their debt, so they resort to revolving that debt from one credit card to the next In 
additron to the foregoing, traditional card technologies can be subject to fraud, fines, or the like. 

Still other technologies available today include modem payment technologies, such as. convenience 
or loyalty cards, radio frequency payment devfces such as Easypay. Speedpass. Fastpay. toll road 
transponders, or the like. Generally, a consumer first enrolls in a payment technology with a merchant or a 
20 gateway service. During enrollment, the consumer often provkJes a credit or debit card account from which 
debits will be made. The merchant then issues, for example, the payment device to the consumer. When the 
consumer desires to purchase products from the merchant, the consumer presents the payment device to, for 
example, a receiver device designed to communfcate with the payment devfce so as to uniquely identify the 
consumer's associated credit or debit card account. The merchant then bills the consumer's card for the 
25 purchase of the products. 

The foregoing payment technologies are finding wider acceptance among consumers as the 
payment technokigles often provide a very convenient payment mechanism, and are finding wider acceptance 
among merchants as payment technologies often generate consumer loyalty. However, because the 
foregoing paynient technologies often employ traditional card technologies as the backend payment 
30 mechanism, these payment technologies unfortunately assume many or all of the foregoing drawbacks 
associated with the traditional card technologies, including, for example, the inability to practically servk» 
smalter, incrementel-type charges. 
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SUMMARY OF THE INVENTIQM 

Based at least in part on the foregoing drawbacks, a need exists for transaction processing system 
that allows consumers to use modem payment technologies without incoiporating the drawbacks of traditional 
credit or debit card techrwiogies. One eriibodiment of the invention includes a transaction processing system 
that converts a transaction produced from virtually any payment device or technology, into electronic debits 
processed through clearinghouse systems as traditional electronic ACH debits to a checking account. Thus, 
the transactkMi processing system advantageously avoids the negative drawbacks of traditional credit or debit 
card technotogies while incorporating the advantages of electronic ACH debit prx)cessing. Moreover, by using 
a checking account for the debit, the transaction processing system advantageously uses the most prevalent 
financial account found in the U.S. population. According to some embodiments, the transaction processing 
system also provkles for the guarantee of payment to the merchant or retailer initiating the transactions. 

According to one embodiment, the transaction processing system includes a merchant system, a 
transactfon processor, an automated clearinghouse system and a user account The transaction prrcessor 
accepts enrollment transaction requests from merchant systems seeking to issue a payment devfce to a new 
user, where the payment device is other than a paper check and designed to access debit funds In the user's 
checking account, For example, the payment device can include cards, transponders, btometric elements, -or 
the like. During enrollment processing, the transaction processor accepte user data, MICR data, the check 
number, and the like. The transaction processor also accepts a transaction date and merchant data, such as 
a merchant's identification number or other data. 

According to one embodiment, the transaction processor processes enrollment transactiwj requests 
by valWating some or all of the user data, by clearing some or all of the user data through negative and/or 
positive databases, assessing a risk score to the enrollment transaction using, for example, a variety of payor 
historical payment variables as well as variables associated with typical transactions in that standard industry 
code (SIC - a four digit code often used to denote differing specific industries). validating-MICR data through 
25 ACH processing, or the like. The transaction processor returns a result of the enrollment transaction to the 
merchant According to one embodiment, the result can include advice on whether to an accept or decline 
the user, an assessed risk score associated with enrolling the user, a result of a negative and/or positive 
database search, some or all of the same, or the like. 

According to another embodiment, the transaction processor also accepts purchase transaction 
30 requests from merchant systems that have recognized a payment device presented by a user as payment for 
a product For example, the merchant system can associate a presented payment device with a unique user 
account directing the merchant to withdraw funds to cover payment from the user's checking account The 
merchant system organizes the infomiation into a purchase transaction request and fonwarxJs the same to the 
transaction processor. During ttie processing of purchase transactions, the transaction processor accepts 
35 data, such as some or all of Hie foregoing user data, some or all of the foregoing MICR data, some or all of 
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the foregoing merchant data, or the like. The transaction processor also accepts specific transaction data 
such as the date, time or amount of the transaction, the product infonnation involved in the transaction, and 
the like. The transaction processor also submits one or more electronic ACH debits rBpresenting the 
transaction to the clearinghouse system. 
5 Moreover, in an embodiment, the transaction processor processes purchase transaction requests by 

validating some or all of the submitted user data, by clearing some or all of the user data through negative 
and/or positive databases, by assessing a risk score to the enrollment transaction, by settling the transaction 
through electronic ACH debit processing, and the like. The transaction processor returns an authorization 
result of the payment transaction to the merchant For example, the result can include advice on whether to 

10 accept or decline the purchase transaction based on an assessed risk score associated with transaction, a 
result of a negative and/or positive database search, some or all of the same, or the like. 

In one embodiment, the merchant may manage the payment device, such as a proprietary loyalty 
card, thereby allowing the users to purchase products at the merchanf s fBtail locations using the payment 
device. Additionally, according to at least one embodiment, a "gateway" can act as an aggregator of sen/ices 

1 5 and provide multiple merchants with the ability to allow payment through the gateway's payment device. For 
example, the gateway may allow users to purchase products at. for example, many differing merchants' retail 
locations using the same payment device. 

For purposes of summarizing the invention, certain aspects, advantages and novel features of the 
invention have been described herein. It is to be understood that not necessarily all such advantages may be 
20 achieved in accordance vyilh any particular embodiment of the invention. Thus, the invention may be 
embodied or carried out in a manner that achieves or optimizes one advantage or group of advantages as 
taught herein without necessarily achieving other advantages as may be taught or suggested herein. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 ^ A general architecture that implements the various features of the invention will now be described with 
reference to the drawings. The drawings and the associated descriptions are provided to illustrate 
embodiments of the invention and not to limit the scope of the invention. Throughout the drawings, reference 
numbers are re-used to indicate correspondence between referenced elements. In addition, the first digit of 
each reference number indicates the figure in which the element first appears. 

30 FIGURE 1 illustrates a diagrammatic representation of an exemplary transaction processing system 

which allows a user to present payment technologies other than checks or credit cards and have payment 
extracted from a debit account, according to an embodiment of the invention. 

FIGURE 2 illustrates an exemplary webpage used to enroll the user in the transaction processing 

system of FIGURE 1, according to an embodiment of the invention. 

35 FIGURE 3 illustrates an enrollment process, according to an embodiment of the invention. 

.4. 
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FIGURE 4 illustrates a purchase process, according to an embodiment of the invention. 

FIGURE 5 illustrates a transaction processing process, according to an embodiment.of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EI\/1B0DIMENTS 
5 A transaction processing system converts the presentation of virtually any payment device or 

technology, into electronic debits to a checking account processed through a clearinghouse system. Thus, 
the transaction processing system advantageously avoids the negative drawbacks of traditional credit or debit 
card technologies while incorporating the advantages of electronic debit processing. Moreover, by using a 
checking account, the transaction processing system uses the most prevalent financial account found in the 
10 banking population. 

As will be apparent, many of the disclosed features may be used without others, and may be 
implemented differently than described herein. Further, although described primarily in the context of a 
transponder based system, the various inventive features are also applteable to types of alternative payment 
devices other than paper checks or credit or debit cards, including, but not limited to loyalty cards, electronic 
15 wallets, one or more smart cards, one or more biometric elements such as a ftumbprint or facial recognition, 
other point-of-sale payment devices, or the tike. The following description is thus intended to illustrate, and 
not limit, the invention. 

According to one embodiment, the transaction processing system includes a merchant system, a 
transaction processor, a user payment device, a clearinghouse system, and a user debit account The 

20 transaction processor accepts enrollment transaction requests from merchant systems seeking to issue a 
payment device to a new user, such as a potential payor, where the payment device is other than a paper 
check and designed to access debit funds in the user's debit account, such as a checking account For 
example, the user can include an individual consumer attempting to make a financial transaction. The 
payment device can comprise a convenience or loyalty card, a transponder, such as radio or other frequency 

25 transponder, an electronic wallet, one or more smart cards, one or more biometric elements such as a 
thumbprint or facial recognition, other point-of-sale payment devices, or the like. During enrollment 
processing, the transactfon processor accepts user data, such as driver's license number or other 
identification infonnation. demographic infomiation such as name, address, birth date, telephone number, 
social security number, or the like, one or more biometric measurements, passwords, or the like. The 

30 transaction processor also accepts MICR data such as scanned or manually entered MICR characters from 
an unused paper check of the user, the check number, or the like. The transaction processor also accepts a 
transaction time, place and date, and merchant data, such as a merchanf s identification number, location, or 
other data. 

35 ENROLLMENT TRANSACTIONS 
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According to one embodiment, the transaction processor processes enrollment transaction requests 
depending upon services generally chosen by the submitting merchant. For example, a merchant may chose 
to have some or all of the user data validated. According to one embodiment, the transaction processor can 
detemilne whether user data, such as, for example, driver's license infomiation, driver's license infonnation. 
MICR data, or the like match those contained in one or more databases accessible to the transaction 
processor. For example, the transaction processor may access a wide number of sources, including credit 
agencies, online information or databases, public records, or the like. According to one embodiment, some or 
all of the user data, social security number. MICR data, or the like is provided by the user during enrollment 

According to one embodiment, a merchant may also choose to have the transaction processor dear 
some or all of the user data through negative and/or positive databases. For example, the transaction 
processor can compare the user's name, driver's license infbnnatkMi. or other demographic information to a 
database of known high risk (negative databases) or known low risk (positive databases) data. When a 
match is found in the negative databases and the merchant desires that the transaction processor guarantee 
future transactwns associated with the enrolling user, the transaction -processor may infonn the merchant 
system to decline enrollment to the user. Altematively, when the processor is not acting as a guarantor, the 
transaction processor may retum inforniatkm informing the merchant of, for example, a negative database 
match. 

A merchant may also choose to have the transaction processor assess a risk score for the 
enrollment transaction. As in known in the art assessing a risk score can advantageously include predfctive 
modeling systems that analyze a plurality of relevant variables in order to detennlne the probability of a 
particular transaction being good or bad, such as the probability the transaction will or viriU not clear the 
banking system via clearinghouse processing. 

Credit risk scoring algorithms generally take^into account those pieces of available data that have 
been determined to be statistically significant The risk score may be a nonnalized value that Indicates the 
probability that the transaction will be good. If the merchant desires that the transaction processor guarantee 
future transactfons associated with the enrolling user as well as process the transaction, the transaction 
processor may simply advise the merchant whether to decline enrollment to the user based on, for example, 
whether the risk score meets a predetemiined threshold. Altematively. if the transactton processor is not 
acting as a guarantor, the transaction processor may compare a merchant's "score card," which Includes 
predetermined values betow which the merchant and/or the processor agree, the risk of loss is acceptaWeto 
the merchant Otherorise. the transaction processor may simply retum the risk score to the merchant system. 
Although risk scoring algorithms are known in general, it will be appreciated that the details of most 
algorithms, including the specific data considered and the weight given various data, are considered 
proprietary by their owners. 
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The merchant may also choose to have the transaction processor validate any ACH processing data. 
According to one embodiment, the transaction processor can perform a validation transaction where a user's 
checking account Is debited and credited for. for example, an equal amount. The result of such debiting and 
crediting can be reported through, for example, settlement files similar to those to be discussed with reference 
5 to purchase transactions. The foregoing validation transactions ensure that the user's account and the 
associated banking institutions are compatible with the processing of electronic ACH debits. 

PURCHASE TRANSACTIONS 

According to another embodiment, the transaction processor also accepts purchase transaction 

1 0 requests from merchant systems that have recognized a payment device presented by a user as payment for 
a product. The merchant system associates the device with a unique account directing the merchant to 
withdraw funds to cover payment from the user's debit account During purchase processing, the transaction 
processor accepts data, such as some or all of the foregoing user data, some or all of the foregoing MICR 
data, some or all of the foregoing merchant data, or the like. The transactfon processor also accepts data 

1 5 related to the specific transaction, such as product infonnation. amount of purchase, time of day, day of week, 
date, location of purchase,- purchaser, cash back amount, type of payment device, and the like. The 
transaction processor also organizes and submits one or more electronic ACH debits associated with the 
transaction to the clearinghouse system. 

Moreover, in an embodiment similar to that disclosed with reference to enrollment transaction 

20 requests, the transaction processor processes transaction requests by validating some or all of the submitted 
user data, by clearing some or all of the user data through negative and/or positive databases, by assessing a 
risk score to the enrollment transaction, by settlement through electronic ACH debit processing, or the like. 
The transaction processor retums an authorization result of the purchase transaction to the merchant As 
disclosed in the foregoing, the fomiat and content of various infonnation within the authorization result may 

25 depend on whether the transaction processor will act as a guarantor for the payment transaction. As 
disclosed, the authorization result can include advice or instmctions on whether to an accept or decline the 
purchase transaction, a risk score to infomi the merchant of a risk associated with accepting the transaction, a 
result of a negative and/or database search, or the like. 

When the transaction processor processes purchase-transaction requests that include settlement. 

30 the transaction processor can send a report, often in the form of a settlement file, to the merchant. For 
example, when the transaction processor processes one or more (e.g., a batch of) transactions, the 
transaction processor may send a preliminary settlement report which is often subject to re.versal. Similar to 
paper check processing, electronic check processing often assumes that transactions are settled, but then 
reverses a transaction when debits and/or credits fail during processing by a clearinghouse system, such as 

35 the ACH. The foregoing settlement file may be sent after one or more transactions have been processed, one 
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or more batches of transactions have been processed, one or more transaction or batches of transactions 
have been processed for a given merchant, some time delay after processing, or the like. Moreover, the 
settlement file may. be sent at intervals of time, at the end of each day. week, or the like. An artisan will 
recognize from the disclosure herein, that when the transaction processor acts as a guarantor for a 
5 transaction, the data related to that transaction in the settlement file is often then not subject to reversal 
because the risk of a failed settlement has been transferred to the transaction processor. 

Thus, the foregoing transaction processing system advantageously altows the association of a 
merchant's payment device to a user's checking account. The transaction processing system provides for 
enrolhnent of the user and the processing of purchase transactions. During enrollment and purchase 
1 0 transaction request processing, the transaction processor can perfomi various services, often chosen through 
preexisting agreements with merchants, such as user data validation, negative and positive database 
searching, risk asse^ments. valuation or settlement processing, or the like. 

To facilitate a complete understanding of the invention, the remainder of the detailed description 
describes the invention with reference to the drawings, wherein like reference numbers are referenced with 
1 5 like numerals throughout. 

FIGURE r illustrates a di^rammatic representation of an exemplary embodiment of a transaction 
processing system 100 which processes transactfons for merchants associated virith payment technologies 
that debit funds of. for example, a user's checking account As shown in FIGURE 1. the transaction 
processing system 100 includes a merchant system 105 designed to communicate with a user enrollment 

20 system 110. a transaction processor 115. and a user payment device 120. FIGURE 1 also shows the 
transaction processor 1 15 communicating with a clearinghouse system 125. According to one embodiment 
at least the merchant system 105. the user enrollment system 110, the transaction processor 115, and the 
clearinghouse system 125 communicate with one anottier through one or more communication links. 

As disclosed in the foregoing, the' user enrollment system 110 communteates with the merchant 

25 system 105 to enroll users into modem payment technologies. The modem payment technologies avoid the 
drawbacks of traditional credit or debit card technologies by associating a debit account 130. such as a 
checking account, with the user payment device 1 20. . During enrollment, the user uses fte enrollment system 
110 to submit various information to the merchant system 105. The merchant system 105 organizes the 
infonnation into an enrollment transaction request and submits the enrollment transaction request to the 

30 transaction processor 115. The transaction processor 115 perfomis various merchant-selected senrices. 
such as those disclosed in the foregoing, and returns an enrollment result to ttie merchant system 105. 
Depending upon the enrollment result, the merchant system 105 may enroll the user by issuing to the user the 
user payment device 120 and associating the devfce to. for example, ttiat user's debit account 130. 

When the user desires to make a purchase from the merchant, the user presents the user payment 

35 devfce 120, and the merchant system 105 uniquely identifies the debit account 130. The merchant system 
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105 submits a purchase transaction request and submits the purchase transaction request to the transaction 
processor 115. The transaction processor 115 performs various merchant-selected services, such as those 
disclosed in the foregoing, and returns an authorization result to the merchant system 105. Depending upon 
the authorization result, the merchant system 105 may complete the purchase by providing the products to 

■ 5 the user and infonning the transaction processor 115 of the same. The transaction processor 115 then 
advantageously performs settlement through the issuance of one or more electronic ACH debit transactions to 
the clearinghouse system 125. thereby transfening funds from the debit account 130 to a credited account 
1 35. such as, for example, the merchant's bank account. 

According to embodiments where the user payment device 120 communicates through, for example. 

10 a wireless signal, the merchant system 105 may include a merchant receiver 140 designed to receive the 
foregoing communications. 

MERCHANT SYSTEM 1Q5 

According to one embodiment, the merchant system 105 includes the components be used to 

15 implement a system which uniquely identifies a debit account when a user presents payment devices other 
than paper checks or credit cards. For example, the merchant system 105 may include one or more central 
server systems 142, which can communicate with one or more merchant receivers 140. one or more user 
account databases 144 and with electronic documents 146. The user account databases 144 can store 
various user data including MICR data which can be used to identify the debit account 130, and the 

20 associated device identifier ("ID") the merchant system 105 will use to recognize the user payment device 
120. For example, as described in the foregoing with respect to enrollment, the user can provide MICR data 
from a check that con-esponds to the account from which funds are to be drawn, such as, for example, the 
debit account ISG.i The MICR data can incfude a routing or bank transit number, generally identifying the 
financial insOtution^r groups of financial institutions that issued the original user's check, an account number 

25 against which the original check is drawn, a check sequence number, various separator symbols often unique 
■ to the financial Institution, and the like. In addition, the MICR data can indicate whether the check is a 
company check or a personal check. The device ID can include an identification number or account number 
which uniquely identifies each user's debit account 130. which may also be used by the sen/er 142 to index 
other data in the user account databases 144. . 

30 The user account database 144 may also include user enrollment data, such as the name, email, 

address, login identifier, password, or the like of each user. The infomiation may also include historical data 
fore each user, siich as transactions, purchases, payments, risk scores, credit histories or other financial 
information, public record data, or the like. 
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Although the user account database 144 is disclosed with reference to one embodiment, a skilled 
artisan will recognize from the disclosure herein that the database can be one or more remote or local 
database systems, or the like. 

In an embodiment where the enrollment system 1 10 includes the use of a computer network; such as 
5 the Internet, the server 142 can also include a web server accessing the electronic documents 146. The 
server 142 generally processes requests for the documents 146. retrieves the documente 146. perfonns any 
necessary processing, and sends the documents 146 to the requesting computer system via the computer 
network. The documents 146 can be used to generate the electronic enrollment pages, user pages helpful in 
managing user accounts, or the like. Moreover, the documents 146 can be used to generate a variety of 
10 pages, such as search and other navigational pages, login, authentication, and authorization pages, online 
stores, and so forth. 

Although the merchant system 105 is disclosed with reference to one embodiment of Internet 
enrollment, the invention is not Intended to be limited thereby. Rather, an artisan will recognize from the 
disclosure herein a wide number of alternative systems providing user enrollment, such as. for example, user 
15 enrollment via the mail, a telephone call, a facsimile, or the like. Often, the enrollment vehicle options are 
limited by rules of the financial institutions governing portions of the transaction, such as. for example, njles 
generated by the National Automated Clearing House Association ("NACHA") or by the national ACH networic. 
Additional information on the processes employed by the ACH. rules of the NACHA. the process of clearing 
paper checks and applying predictive scoring algorithms for risk assessment, can be found in U.S. Pat. No. 
20 5,679,940, issued to Templeton et al. on October 21, 1997. entitled ''Transaction System Witt) On/Off Line 
Risk Assessment; which is incorporated herein by reference, and is generally considered with the scope of 
knowledge possessed by one of ordinary skill in the banking community. 

In addition, the merchant system 105 can include or comprise any device that interacts with or 
provides data to the merchant receiver 140. the user enrollment system 110. or the transaction processor 
25 115. including by way of example, any Internet site, private networi(s, networic servers, video delivery 
systems, audio-visual media providers, television programming providers, telephone switching networi(s. teller 
networi^s, wireless communication centers or the like. 

Moreover, the merchant system 105 may include one or more satellite or store computer systems 
throughout a geographically diverse networic. Each store system may be located within proximity to a 
30 merchant receiver, and may advantageously communicate with one or more servers or the server system 142 
to access user infomiation stored in one or more database collections, such as, for example, the user account 
database 144. 
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USER ENROLLMENT SYSTEM 1 10 

FIGURE 1 also shows the transaction processing system 100 comprising the user enrollment system 
110. According to one embodiment, the user enrollment system 110 comprises one or. more computer 
systems allowing a user to interact with the merchant system 105 via a communication link. In one 
5 embodiment, the computer is equipped with a modem or other communication device configured to 
communicate with aspects of the merchant system. 105. The computer may comprise, by way of example, 
processors, program logic, or other substrate configurations representing data and instructions, which operate 
as described herein. In other embodiments, the processors can comprise controller circuitry, processor 
circuitry, processors, general purpose single-chip or multi-chip microprocessors, digital signal processors. 
10 embedded microprocessors, microcontrollers and the like. In addition, the user enrollment system 110 can 
comprise a computer woricstation. a local area networic of individual computers, a kiosk, a point-of-sale 
device, a personal digital assistant, an interactive vwreless communications device, an interactive television, a 
transponder, or the like. 

In one embodiment, the user employs the user enrollment system 110 to enroll with the merchant 

15 system 105. For example, the merchant system 105 may advantageously present an electronic enrollment 
form to the user through the user enrollment system 1 10. The enrollment torn can include an entry for data 
associated with the debit account the user virishes to tie to the payment device 120, such as, for example. 
MICR data from an unused check. According to one embodiment, the enrollment fomi may also include an 
explicit authorization from the user, authorizing the merchant, the processor, or both, to generate electronic 

20 debits and credits from a selected user debit account 

When the user has completed the enrollment torn, the user enrollment system 110 transfers the 
entered information to the merchant system 105. where it is stored, for example, in the user account database 
1 44. An exemplary enrollment process is disclosed with reference to FIGURE 3. 

Although the enrollment system 110 is disclosed with reference to an embodiment of Internet 

25 enrollment, the invention is not intended to be limited thereby. Rather, as disclosed, a wide number of 
alternative systems can provide user enrollment, such as, for example, user enrollment via the mail, a 
telephone call, a facsimile, or the like. Often, the enrollment vehicle options are limited by rules of the 
financial institutions governing portions of the transaction, such as, for example, rules generated by NACHA 
for the national ACH networic. 

30 FIGURE 1 also shows the merchant system 105 including server code 148. The server code 148 

advantageously includes one or more software processes or program logic designed to execute on the server 
systems 142. In one embodiment, the server code 148 may advantageously include software or hardware 
cornponents such as software object-oriented components, class components and task components, 
processes methods, functions, attributes, procedures, subroutines, segments of program code, drivers. 

35 firmware, microcode, circuitry, data, databases. data structures, tables, arrays, and variables. As illustrated in 
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FIGURE 1, the server code includes enrollment process code for enrolling users into the transaction 
processing system 100, and purchase process code for allowing users to purchase products by presenting 
their user payment devices 120. 



5 TRANSACTION PROCESSOR 115 

According to one embodiment, the transaction processor 1 15 comprises one or more server systems 
152 communicating with one or more database collections to detemiine whether to authorize particular 
transactions presented by the merchant system 105. The database collection can comprise one or more 
logical and/or physical data storage systems for storing the data used by the transaction processor 1 15. and 
1 0 may comprise two or more separate databases and/or storage systems or networics of storage systems. 

As shown in FIGURE 1 . the database collection comprises a historical transaction database 1 54. and 
a MICR line conversion database 156. The historical transaction database 154 advantageously stores 
infonnation about the users' financial history, and may include transaction data from transactions processed 
by the transaction processor 115. other systems, credit reporting companies, or other commercially available 
1 5 databases. The historical transaction database 1 54 can include infonfnation from, for example, credit reports, 
online activities by the user, other user data, or the like. The historical transaction database 154 can 
comprise multiple databases, such as. for example, a positive database storing positive risk information, and 
negative databases storing high-risk infonnation or names of otherwise unqualified individuals. 

The MICR line conversion database 156 includes infonnation regarding the fonnatting of transactions 
20 submitted to the clearinghouse system 125. For example, the MICR line conversion database 156 can 
include historical and other infonnation regarding the placement and use of differing MICR character by 
various banking institutions or check printing companies, thereby providing the transaction processor 1 15 with 
conversion infonnation for converting the user entered checking account;data. sueh as thaMICR line, into, for 
example, electronic ACH debit or credit transactions. The MICR data and/or historical data stored in the 
25 MICR line conversion database 154 can also include routing numbers, account or check number, payable 
through credit institutions, traditionally absent numbers, or the like. 

FIGURE 1 also shows the transaction processor 115 including server code 158. The server code 
158 advantageously includes one or more software processes or program logic designed to execute on the 
.server systems 152. In one embodiment, the server code 158 may advantageously include software or 
30 hardware components such as software object-oriented components, class components and task 
components, processes methods, functions, attributes, procedures, subroutines, segments of program code, 
drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and varialjles. 

As shown in FIGURE 1. the server code 158 includes transaction process code, and enrollment and 
purchase processing code. The transaction process code advantageously perfontjs various merchant 
35 selected services, such as, for example, user data validation, negative and/or positive database searching, 
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risk scoring, account information validation, settlement processing, or the lilte. The transaction process code 
also returns enrollment and authorization results. As disclosed, various information within the authorization 
result may depend on whether the transaction processor will act as a guarantor for the payment transaction. 
As disclosed, the authorization result can include advice or instmctions on v^hether to an accept or decline the 
5 payment transaction, a risk score to inform the merchant of a risk associated with accepting the transaction, a 
result of a negative and/or database search, or the like. 

USER PAYMENT DFVir.F 1?n 

I 

As disctosed in the foregoing, the user payment device 120 allows users to make purchases by 
10 presenting the device 120 to the merchant system 105, and having the appropriate funds withdrawn from the 
debit account 130. According to one embodiment, the user payment device 120 can comprise a wkle variety 
of point-of-sale payment devices. For example, the user payment device 120 can comprise radio or other 
frequency transponders, such as toll transponders designed to automatically communicate with tollbooths. 
thereby avoiding the need to stop and pay cash to use a toll road. The user payment device 120 may 
15 comprise transponders designed to communicate with gas statfons for the payment of fuel at the pump. 
Transponders may be used to conveniently pay for drive through servfces. grocer checkout counters, or 
virtually any place where payment through a wireless device makes for convenient, efficient, purchases. 
According to one embodiment, the user payment device 120 can comprise a computing device, a personal 
digital assistant, a wireless telephone or the like. Moreover, according to one embodiment, the user payment 
20 device 120 transmits various data when it detects the presence of a receiver for the same. Other 
embodiments may include the ability to receive data from or otherwise communicate vinth, for example, the 
merchant system 105. 

According to another embodiment, ttie user payment device 120 may comprise loyalty caixls such as 
those used by many grocers, or the Nke. In such embodiments, the user payment device.120 may include a 
25 magnetic stripe and/or number designed to uniquely identify Uie debit account 130. According to yet another 
embodiment, the user payment device 120 may comprise biometiic solutions such as those used by quick 
serve restaurants including thumbprints, facial recognition, or the like. Ottier embodiments include electrons 
wallete. one or more smart cards, or ttie like. 

As disctosed in the foregoing, the user payment device 120 can advantageously -be associated vintti 
30 the merchant, and therefore, can often generate loyalty in customers as ttiey desire to use their devfce 
instead of canying cash or using expensive credit card technologies. 

m 

CLEARING HOUSE NETWORK 

According to one embodiment, the clearinghouse system 125 comprises the national ACH network. 
35 Generally, the ACH networi( can accept electronic ACH debit and credit transactions against, for example, the 
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user-sdebit account 130. When the transaction processor 115 settles a transaction twtween the user and the 
merchant, the transaction processor 115 advantageously fomiats at least one electronic ACH debit 
transaction debiting the user's debit account 130, and crediting the credited account 135. The foregoing 
electronic ACH debit and credit transacUons are then transferred into the national ACH networ* as electronic 
5 transactions. Rules for the format and content of the electronic ACH debit and credit transactions are 
governed by NACHA and considered within the scope of Icnowledge for an artisan within the electronic 
banking industry. 

Although the clearinghouse system 125 is disclosed with reference to this embodiment the invention 
is not intended to be limited thereby. Rather, a skilled artisan will recognize from the disclosure herein a wide 
10 number of alternatives for the clearinghouse system 125. For example, the clearinghouse system 125 may 
comprise one or more private institutions that have developed a networic for clearing electronic transactions 
between users thereof. Such private systems generally promulgate rules governing the type and content of 
electrons transaction submissions. 

15 MERCHANT RECEIVFR lit) 

FIGURE 1 also shows the transaction processing system 100 including the merchant receiver 140. 
The merchant receiver 140 communicates with, or receives the transmission from, the user payment device 
120. The merchant receiver 140 may be a toll receiver designed to automatically read a toll transponder of a 
motorist, may be a receiver designed to read a transponder waved in front of. for example, a fuel pump, or the 
like. According to one embodiment, the receiver 140 communkates with the merchant system 105 to 
uniquely identify the user, the user's checking account data, blometric readers or scanners, or the like. 

Other embodiments may include a magnetic stripe reader or other system designed to read the 
Infonnation found on loyalty cards or the like. j : 

25 COIVIMUNICATIQN I IMK.<; 

FIGURE 1 also illustrates various components communicating with one another through 
communicatfon links. In one embodiment, the communicaBons links include portions of the Internet, which is 
a global networic of computers. In other embodiments, the communications links may be any communfcation 
system including by way of example, telephone nefworics, wireless data transmission systems, two-way cable 

30 systems, computer networi(s. interactive kiosk networtcs. automatic teller machine networi<s, interactive 
television networks, and the like. 

Based on the foregoing disclosure, the transaction processing system 100 advantageously provides 
users with the convenience of using the payment devices 120 instead of carrying cash or using expensive 
traditional card technotogies. Moreover, the transaction processing system 100 advantageously provides 
35 merchants with the ability to select from many risk detemiining or risk guarantee services, while also allowing 
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for automated processing through the clearinghouse system 125, which is generally significantly less 
expensive than the minimum fixed cost fees associated with the traditional card technologies. 

Although the transaction processing system 100 has been disclosed with respect to various 

m 

preferred and alternative embodiments, an artisan will recognize from the disclosure herein that a wide 
number of differing devices can accomplish the functionality disclosed. For example, the merchant system 
105 and the transaction processor 115 may advantageously be governed by. and/or comprise a single entity 
or system. Moreover, layered gateway systems may offer users the ability to use the gateway's payment 
device in multiple retail locations of multiple merchants, without departing from the scope of the present 
disclosure. 



EXEMPU^RY ENROLLMENT FORM 

FIGURE 2 illustrates an exemplary webpage 200, wrtiich can be used to enroll the user into the 
transaction processing system 100, according to an embodiment of the invention. As shown in FIGURE 2. 
the webpage 200 comprises user demographic infomiation 205, such as name, address, email, age. social 

1 5 security number, gender, or other historical or demographic infomiation desired by the merchant or processor 
to. among other things, develop accurate risk assessments of the user. The webpage 200 also includes an 
account selection button 210. providing the user the ability to associate, for example, payments from the user 
device 120. to the debit account 130. According to one embodiment, the user can select his or her checking 
accoum. According to other embodiments, the user may select a credit canl or other financial accounts. 

20 When the user desires to tie his or her payment device 120 to the debit account 1 30, the webpage 

200 also includes an entry section for entry of debit account data 215. As shown in FIGURE 2. the debit 
account data 215 can include MICR data from an unused check. According to one embodiment, the user may 
be prompted to enter an asterisk (*). or other placeholder character, in place of the non-numeric symbols that 
are included in many MICR characters printed on a check. Alternatively, the webpage 200 may include an 

25 interactive portion whfch alfows users to select from a given set of non-numeric MICR symbols to be added to 
their MICR date. Other embodiments may include instnrctions on how to create and/or attach a scanned 
image of an unused check, or a file containing data from a MICR line optical and/or magnetic reader. In such 
embodiments, the merchant or the processor may incorporate hardware and/or software components 
designed to interact with such date to extract the MICR date, such as, for exampte, optical- character 

30 recognition ("OCR") software, or the like. As shown in FIGURE 2. the webpage 200 may request MICR data 
be entered twice, thereby advantageously allowing the merchant system 105 to compare each entry so as to 
ensure conect entry thereof. : ■ 

Embodiments of the enrollment webpage 200 also include an authorization section 220. where the 
user expliciUy authorizes the merchant system 105 and/or the transaction processor 1 15 to perform electronic 

35 ACH.debit and credit transactions to his or her selected debit account. Such authorization may include a 
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separate button indicating the user has read and understands the same, may have limitations such as a "not 
to exceed" limitation, or the like. In addition, the webpage 200 includes a submit button 225, which transfers 
the user-entered data from the user enrollment system 1 10 to the merchant system 105. 

Although the webpage 200 is disclosed with reference to an exemplary embodiment, an artisan will 
5 understand from the disclosure herein that the webpage 200 may include a wide variety of interactive buttons, 
fomis. updated electronic pages, menu selections, multimedia explanations or other presentations, or the like. 
Moreover, the webpage 200 may request that the user upload a digital picture or scanned image of the user 
or various user documents, such as a driver's license, social security card, government ID, .or the like. In 
addition, the webpage may include one or more printable forms which a user can email, mail or fax to the 
10 merchant system 105. 

As disclosed in the foregoing, the transaction processing system 100 can include a wide variety of 
other enrollment mechanisms, and the exemplary online enrollment fonn 200 is not meant to limit the scope of 
the disclosure. 

15 ENROLLMENT PROCESS 300 

FIGURE 3-illustrates an enrollment process 300. according to an embodiment of the invention. As 
shown in FIGURE 3. the enrollment process 300 generally Includes the user transfening various demographic 
and account data to the merchant system 105, which in one embodiment, fomiats an enrollment transaction 
request to be processed by the transaction processor 115. 

The exemplary enrollment process 300 begins at BLOCK 305, where the user enters the user data 
into the enrollment system 110. As described in the foregoing, the user data can include a user name, 
address, social security number, email, government identification, corporate identification logins, passwords, 
biometric data such as a fingerprints or facial scans, driver's license infonnation such as license number or 
the like, scans of some or ail of the foregoing documents, outputs from magnetic stripe or other card readers, 
25 or other data helpful in assessing a risk associated with enrolling the user in the transaction processing 
system 100. 

At BLOCK 310. the user enters MICR data from one of his or her checks associated with the debit 
account 130 from which funds can be drawn. As described in the foregoing, the MICR data can include MICR 
characters, such as an account number, the bank transit number, the check sequence number, type of check, ' 
30 and the like. According to embodiments disclosed in the foregoing, the MICR data may also include 
placement holder characters in place of the non-numeric symbols that are included in their MICR line, or the 
like. According tor one embodiment, the MICR data read by a scanning or reading device and entered into the 
enrollment system 110. 

At BLOCK 315. the user authorizes the merchant system 105 and the transaction processor 115 to 
35 submit electronic ACH debits against the debit accourit 1 30 when the user presents.the user payment device 
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120 as payment for products. As disclosed in the foregoing, such authorization can be governed by rules 
promulgated by the clearinghouse system 125. 

At BLOCK 320, the merchant system 105 organizes various user-submitted infonmation into an 
enrollment transaction request, and submits the same to the transaction processor 1 15. The form and fomiat 
5 of the enrollment transaction request can be designated or defined by the merchant system 105 and/or 
transaction processor 115, and according to one embodiment, can include infonnation identifying the 
merchant, Identifying the user, date and time infomiation, infomiation designating the user^s account data, 
such as MICR data, merchant infomiation, or the like. The enrollment transaction request may also include 
additional information useful in assessing the risk of the user, such as. for example, a driver's license or social 
10 security number, address, credit card data, or other demographic or financial data. 

Alter the transaction processor 115 processes the enrollment transaction, such as, for example, 
according to various disclosed merchant-selected services, the transaction processor retums an enrollment 
result According to embodiments disclosed* herein, the enrollment result provides an indication to the 
merchant system 110 of the risk associated with accepting the enrollment of the user in the transaction 
1 5 processing system 1 00. 

At BLOCK 325, the merchant system 105 confimis the receipt of that result, and can further instruct 
the transaction processor 1 15 to validate the enrolling user's account infomiation. For example, the merchant 
system 105 may desire to ensure that the banks, financial institutions, or the like, associated with the debit 
account 130, support the submission of electronic ACH debit transactions. According to one embodiment, the 

20 merchant system 105 instmcts the transaction processor 115 to fomnat and submit an electronic ACH debit 
and credit for equal amounts against the debit account 130. thereby validating that the account information 
supports electronic ACH processing. 

At BLOCK 330. the merchant system 105 receives the report from the transaction processor 115 
detailing, for example, the results of the validation of account information, the risk associated with enrolling 

25 the user, pennission to enroll the user in embodiments where the transaction processor 115 acts as a 
guarantor, one or more settlement files, or the like. Upon receipt of the report, the merchant system 105 can 
advantageously determine whether to enroll the user into the transaction processing system 100. 

Based on the foregoing, the enrollment process 300 advantageously provides assurances to the 
merchant system 105 on whether the enrolling user is within an acceptable credit risk and whether the user- 

30 selected debit account 130 and associated banking institutions allow for electronic transactions through the 
clearinghouse system 125. 

Although disclosed with reference to prefenred and alternative embodiments, an artisan will 
recognize from the disclosure herein that the enrollment process 300 may advantageously include portions or 
all of the foregoing functionality, without departing from the spirit or scope of aspects of the invention. 



35 
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PURCHASE PROCESS 400 

FIGURE 4 illustrates a purchase process 400, according to an embodiment of the invention. As 
shown in FIGURE 4. the purchase process 400 generally includes the user presenting the user payment 
device 120 to the merchant receiver 140 as payment for one or more products, where the payment is to be 
debited from the debit account 130. The merchant system 105 recognizes the payment device 120, 
determines the corresponding account infonmation, and fomiats a purchase transaction request to be 
processed by the transaction processor 115. Based at least in part upon the processing by the transaction 
processor 115. the merchant system 105 will detemiine whether to allow the user to purchase the one or 
more products using the payment device 120. 

The exemplary purchase process 4Q0 begiris at BLOCK 405, where the user presents his or her user 
payment device 120 to the merchant receiver 140 as payment for one or mote products, where the payment 
is to be debited from the debit account 130. As disclosed in the foregoing, the presentment may be of a 
transponder, a loyalty card, a biometric. a smart card or the like, to a corresponding system designed to read 
sufficient information to uniquely locate the corresponding account infomiation, such as, for example account 
infomiation stored in the user account database 144. At BLOCK 410. the merchant system 105 identifies the 
user payment device 120. accesses the relevant account infomiation, and fbmiats a purchase transaction 
request to be processed by the transaction processor 115. 

As described in the foregoing, the fonn and fomiat of the purchase transaction request can be 
designated or defined by the merchant system 105 and/or transaction processor 115. and according to one 
embodiment, includes information identifying the merchant, identifying the user, date and time infomiation. 
infomiation designating the user's account data, such as MICR data, product infomiation, amount of 
purchase, time of day. day of week, date, location of purchase, purchaser, cash back amount, type of 
payment device, and the like. The purchase transaction request may also include addittonal ioformatioh 
useful in assessing the risk of the transaction, such as. for example, a user driver's license or social security 
number, address, credit card data, or other demographic or financial data. 

After the transaction processor 115 processes the purchase transaction, such as. for example, 
according to various disclosed merchant-selected services, the transaction processor 115 returns an 
authorization result. According to embodiment disclosed herein, the authorizatfon result provides an 
indfcation to the merchant system 105 of the risk associated with accepting the transaction. According to one 
embodiment when the authorization result was positive, or within predetermined acceptable ranges of risk, 
the merchant system 1 10 can finalize the purchase with the user. 

At BLOCK 420, the merchant system 105 confimis the receipt of the authorization result, and can 
further instmct the transaction processor 115 whether the purchase was finalized between the user and the 
merchant system 105. When the purchase was finalized the merchant system 105 confimis receipt of the 
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authorization results and transmits an indication to the transaction processor 115 that the purchase was 
finalized and settlement should be processed. 

According to one embodiment, the transaction processor 115 uses the MICR conversion data from 
the mCR conversion database 156. to translate the MICR data into that infomiation desired by the 
5 clearinghouse system 125. The transaction processor 1 15 then fonnats and submits an electronic ACH debit, 
which Includes the foregoing infonnation, to the clearinghouse system 125, 

Based on the foregoing, the purchase process 400 advantageously advises, and often guarantees 
that the purchase transaction is within an acceptable credit risk for the merchant. Moreover, the purchase 
process 400 perfbnns settlement processing. Although disclosed with reference to prefen-ed and alternative 
10 embodiments, an artisan will recognize from the disclosure herein that the purchase process 400 may 
advantageously include portions or all of the foregoing functionality, without departing from the spirit or scope 
of aspects of the invention. 

TRANSACTION PRQCE<;<^ 

15 FIGURE 5 illustrates a transaction processing process 500, according to an embodiment of the 

invention. As showri in FIGURE 5, the transaction processing process 500 generally Includes the transaction 
processor 115 receiving one of an enrollment transaction request or a purchase transactton request from the 
merchant system 105. Based on which services the merchant selected, the transaction processing process 
500 perfomis various levels of risk assessment and. in some cases, may guarantee the transaction. Thus. 

20 according to one embodiment, the actions of the transaction processing process 500 will vary depending upon 
the service selections of the merchant. The transaction processing process 500 also can validate various 
account infonnation and/or perform settlement processing through communication with the clearinghouse 
system 125. 

According to one embodiment, the transactton processing process 500 begins at BLOCK 505 where 
25 the transaction processor receives one of an enrollment transaction request or a purchase transaction request 
from the merchant system 105. As described in the foregoing, when the merchant-selected sen/ices include 
one or more of user data validation, clearance of the negative and positive databases, assessment of risk 
scores, or the like, the transaction processor 115 performs those activities with respect to the information 
provided In the particular transaction request, as illustrated in BLOCKS 510-520 of FIGURE 5. 
30 At BLOCK 525, the transaction processor 115 transmits the results of the foregoing processing back 

to the merchant system 105.- As described, at BLOCK 530. the merchant system 105 confimis the receipt of 
the transaction results, and instructs the transaction processor 115 to validate the account data associated 
with an enrollment transaction request, settle the purchase associated with a purchase transaction request, or 
the like. 
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When validation or settlement is desired, at BLOCK 540, the transaction processor Ibrmats the 
appropriate electronic ACH submissions by, for example, the conversion of the MICR data into infoimation 
used by the clearinghouse system 125. For example, the transaction processor 115 perfomis settlement by 
debiting the debit account 130 by an amount corresponding to the purchase transaction amount Moreover, 
5 the transaction processor 115 submits a credit of the foregoing amount, minus in one embodiment, the 
processor's fees, to the credited account 135. At BLOCK 545, the transaction processor 115 submits the 
electronic ACH debits or credits to the clearinghouse system 125. At BLOCK 550, the transaction processor 
1 15 reports Uie results back to the merchant system 105. 

As disclosed in the foregoing, the reports can advantageously include one or more settlement files 
10 corresponding to one or more transactions or batches of transactions having been just processed or 
processed some time before. Also as disclosed, when the transaction processor 1 15 acts as a guarantor tor 
a particular transaction, the data related to that transaction in the settlement file is often then ncrt subject to 
reversal. 

Based on the foregoing, the transaction processing process 500 advantageously employs the 
15 clearinghouse system 125 to settle payments made using the payment device 120, or validate account date 
submitted at enrollment. The clearinghouse system 125 generally perfomis the settlement purchases faster, 
more reliably, and at a significantly lower rate than the fixed minimum and other fees of traditional credit 
cards. In similar fashion, the transaction processing system 100 disclosed in the foregoing advantageously 
adopts many of the conveniences for users and merchants of credit card payments, without incorporating the 
20 high costs of the same. 

Although the foregoing invention has been described in tenns of certain prefened embodiments, 
other embodiments will be apparent to those of onlinary skill in the art from the disclosure herein. 
Additionally, other combinations, omissions, substitutions and modifications will be apparent to the skilled 
artisan in view of the disclosure herein. While certain embodiments of the inventions have been described, 

25 these embodiments have been presented by way of example only, and are not intended to limit Vhe scope of 
the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of 
other forms without departing from the spirit thereof. The accompanying claims and their equivalents are 
intended to cover such forms or modifications as would fall within the scope and spirit of the inventfons. 

In addition to the foregoing disclosure, all publfcations, patents, and patent applications, or other 

30 references mentioned in this specification are herein incorporated by reference to the same extent as if each 
individual document was specifically and individually indicated to be incorporated by reference. 
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WHAT IS CLAIMED IS: 

1 . A financial transaction system configured to accept as payment for goods or services the 
presentation by a payor of a payment device ottier than a paper check, a credit card or a debit card, the 
financial transaction system comprising: 

a payment device other than a paper check, a credit card or a debit card, where 
presentation of the payment device for goods or services indicates that funds are to be drawn on a 
checking account of a payor to pay for the goods or sen/ices in an electronic transaction; 

a point of sale device which receives from the payment device, identification data useable 
to unk]uely identify the payment device; and 

one of mote computing devices that assess risk wherein the one or more computing 
devfces assess the risk of the electronic transaction, and accept or decline the payment for the 
goods and services. 

2. The financial transactfon system of Claim 1, wherein the payment device comprises a 
transponder. 

3. The financial transaction system of Claim 1 . wherein the payment device comprises one or 
more loyalty cards. 

4. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more smart cards. 

5. The financial transaction system of Claim 1. wherein the payment device comprises a 
computing device. 

6. The financial transaction system of Claim 5. wherein the paymert device comprises a 
personal digital assistant. ; : 

7. The financial transaction system of Claim 1. wherein the payment device comprises a 
mobile telephone. / 

8. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more biometric elements. 

9. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more devfces storing or using biometric data. 

* 

10. The financial transaction system of Claim 1. wherein the point of sale device comprises a 
wireless receiver. 

11. The financial transaction system of Claim 1, wherein the point of sale' device comprises a 
magnetic stiip reader. - 
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12. The financial transaction system of Claim 1, wherein the one or more computing devices 
include gateway computing devices which allow secondary merchants to accept presentation of the payment 
device for goods and services. 

13. The financial transaction system of Claim 1, wherein the electronic transaction includes an 
enrollment transaction designed to determine whether the payor meets predetemiined criteria set by the 
financial transaction system. 

14. The financial transaction system of Claim 1, wherein the one or more computing devices 
receive results from a transaction processing system. 

15. The financial transaction system of Claim 14, wherein the results include an authorization to 
accept the presentation of the payment device as payment for the goods or services. 

16. The financial transaction system of Claim 14, wherein the results include an authorization to 
enroll the payor with the financial transaction system by providing the payor with the payment device. 

17. The financial transaction system of Claim 1 wherein the one or more computing devices 
comprise: 

• - . 

a server system including a merchant receiver configured to recognize the payment device 
presented by the user as payment for goods or services; and 

one or more databases storing MICR data used to identify the checking account 

18. The financial transaction system of Claim 1 further comprising: 

identification infomiation converston data usable to convert the identification data into 
information used by a clearinghouse system to perform electronic check processing; and 

historical transaction data usable to assess the risk of performing the electronic transaction. 

19. The financial transaction system of Claim 1, wherein the one or more computing devices 
perform settlement processing. - ' 

20. The financial transaction system of Claim 1, wherein the one or more computing devices 
perform validation processing. 

21. A method of accepting a payment device as payment for goods or services, the method 
comprising: 

receiving identification information from a payment device presented by a user for payment 
of goods or services, wherein the payment device is not a paper check, a-credit card, or a debit card; 

determining checking account data associated with the 'payment device wherein 
presentation of the payment device indicates that, funds are to be drawn on a checking account of 
the user; 

initiating an electronfo transaction using the checking account data; 
obtaining an assessment of a risk of the electronic transaction; and 
. accepting or declining the paymerit for the goods or services. 
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22. The method of Claim 21. further comprisirig enrolling the user by issuing the payment 
device and obtaining the checking account data. 

23. The method of Claim 22, further comprising obtaining an assessment of a risk of enrolling 

the user. 

5 24. The method of Claim 22 further comprising acquiring information identifying the user 

attempting to enroll into a system providing for the payment goods or seivices from the checking account of 
the user through the presentation of the payment device. 

25. The method of Claim 24, wherein the information includes information found on the user's 
driver's license. 

1 0 26. The method of Claim 24, wherein the information includes demographic infonnation. 

27. The method of Claim 24 wherein the infomiation includes biometric information. 

28. The method of Claim 24. wherein the information includes password infbmiation. 

29. The method of Claim 21, wherein the assessment of the risk is acquired through a 
transaction processor. 

^5 30, . The method of Claim 2 1 wherein obtaining the assessment of risk is based on one or more 

characteristics of the electronic transaction 

31. The method of Claim 30 wherein the checking account information comprises MICR data. 

32. The method of Claim 31, wherein the one or more characteristics of the electronic 
transaction include whether the MICR data is valid. 

20 33. The method of Claim 31, wherein the MICR data is valid when it can be converted into 

information used by clearinghouse systems to transfer funds. 

34, The method of Claim 30, wherein the one or more characteristics of the electronic 
- transaction include whether an assessed risk of the electronic transaction is within predetemiined parameters. 

35. The method of Claim 34, wherein the assessed risk includes an evaluation of historical 
25 transaction infonnation. 

36, The method of Claim 35, wherein the historical transaction information includes negative 
transaction infomiation. 

37. The method of Claim 35, wherein the historical transaction infonnation includes positive 
transaction information. 

30 38. The method of Claim 30, wherein the one or more characteristics of the electronic 

transaction include whether the electronic transaction will be guaranteed. 

39. The method of Claim 21 , further comprising transmitting MICR data to a gateway system. 

40. The method of Claim 21. further comprising transmitting infonnation to a gateway system, 
and wherein the gateway system detennines whether to accept or decline the electronic transaction. 

35 41 . The method of Claim 21 , wherein the payment device comprises a transponder. 
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